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PROCEDURE SUMMARIES FOR MULTITHREADED SOFTWARE 

TECHNICAL FIELD 

The technical field relates to analysis of multithreaded software, such as 
5 modeling and testing multithreaded software. 

BACKGROUND 

The sheer complexity of the software development process makes it increasingly 
difficult for programmers to detect programming flaws. As a result, software testing 
10 has become an important part of software development. 

Software can be tested by a human tester who executes the software and 
monitors its progress. However, as the complexity of the software increases, it becomes 
virtually impossible for a person to reproduce all possible execution scenarios in a 
reasonable amount of time. Therefore, testers can build a model of the software to 
15 model (e.g., simulate) execution of the software. Because modeling allows automated 
exploration of the software, it can perform a more extensive analysis than what is 
possible by human analysts. 

One technique for modeling software is procedure summarization. Procedure 
summaries can represent a summarization of calculations done in software. In this way, 
20 calculations during modeling can be simplified, and more efficient modeling of 
execution can be performed. 

For example, if during execution, the software has state s when it enters a 
procedure P and state s 1 when it exits the procedure, a summary of the procedure can 
include the following state pair: 

25 

In practice, the summary of a procedure contains such a state pair if in state s 
there is an invocation of P that yields the state s ' on termination. Thus, the summary 
can include plural state pairs, one for each possible pair of initial state and resulting 
states. The procedure summary can be used in place of executing the procedure during 
30 modeling. 
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Procedure summaries have been used with success for sequential programs. 
However, for multithreaded software, some of the state variables may be shared by 
multiple threads. Thus, conventional procedure summaries are of little use. For 
example, during execution of the procedure, updates to shared state variables may be 
performed by interleaved actions of concurrently executing threads. Such actions may 
depend on the local states of the other threads. Therefore, the state pairs do not 
accurately reflect the possible resulting states in a multithreaded execution scenario. 

So, there still exists a need for improving procedure summary technology. 

SUMMARY 

Procedure summaries can be generated for multithreaded software and used to 
model execution of multithreaded software. For example, a set of actions for a 
procedure can be identified as atomically modelable with respect to multithreaded 
execution of the actions. Atomic modelability can include the property that the actions 
can be modeled together without regard to possible interleaved actions from other 
threads. The actions can be deemed to have occurred one after the other without 
interruption by other threads. For such actions, a partial summary of the procedure can 
be constructed. A procedure summary can then include one or more such partial 
summaries. During modeling, the partial procedure summaries can be used to 
accurately model state during multithreaded execution (e.g., even if execution of the 
procedure by one thread is subject to interrupting by other threads sharing state 
variables.) 

Such sets of actions can be described as a transaction. Actions in the transaction 
can be deemed to have occurred one after another without interruption by other threads. 
A multithreaded program can thus be modeled as a series of such transactions. 

In addition, a variable local to each thread can track the phase of a transaction 
for the thread. By watching the variable, transaction boundaries can be determined. 

Programming flaws can be detected via the procedure summaries. For example, 

a program can include specified invariants (e.g., assert statements), and the procedure 

summaries can be used to identify when an invariant fails. 
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The partial procedure summaries can indicate an initial and resulting location 
(e.g., a program counter) in the procedure. In this way, the partial procedure summaries 
can be pieced together. 

The procedure summaries can allow reuse of analysis results across different 
call sites in a multithreaded program. For example, a reachability analysis can employ 
procedure summaries for multithreaded programs. 

The mover status of procedure actions can be determined. Based on the mover 
status, a set of actions atomically modelable with respect to multithreaded execution of 
the software can be identified. For example, a transactional boundary can be found 
according to the mover status of the actions. 

The procedure summaries can be used to model various multithreaded programs 
that use shared variables, synchronization, and recursion. For example, a single 
transaction can be used to model recursion. 

The foregoing and other features and advantages will become more apparent 
from the following detailed description of disclosed embodiments, which proceeds with 
reference to the accompanying drawings. 

BRIEF DESCRIPTION OF THE FIGURES 

FIG. 1 is a block diagram showing an exemplary system for analyzing 
multithreaded software via procedure summaries. 

FIG. 2 is a flowchart showing an exemplary method for analyzing multithreaded 
software via procedure summaries, such as with the system shown in FIG. 1. 

FIG. 3 is a block diagram showing an exemplary model checker using procedure 
summaries for analyzing multithreaded software. 

FIG. 4 is a flowchart showing an exemplary method using reachability and 
procedure summaries to analyze multithreaded software. 

FIG. 5 is a block diagram showing exemplary partial summaries for a procedure. 

FIG. 6 is a flowchart showing an exemplary method for generating partial 

procedure summaries. 

FIG. 7 is a block diagram showing exemplary actions for a procedure. 

-3- 



GLM/JDW 12/19/2003 3382-66774 # 306109.01 Express Mail Label No. EV331581388US 

Date of Deposit: December 19, 2003 

FIG. 8 is a block diagram showing exemplary partial procedure summaries 
based on actions of a procedure. 

FIG. 9 is a flowchart showing an exemplary method for generating partial 
procedure summaries based on actions of a procedure. 
5 FIG. 10 is a block diagram showing exemplary summary boundaries for partial 

procedure summaries. 

FIG. 1 1 is a flowchart showing an exemplary method for identifying partial 
procedure summary boundaries. 

FIG. 12 is a block diagram showing an exemplary format for representing a 
10 partial procedure summary. 

FIG. 13 is a block diagram showing an exemplary arrangement involving left 
movers and right movers. 

FIG. 14 is a block diagram showing an exemplary set of instructions included 
for computing a partial procedure summary based on the right and left mover status of 
15 the actions. 

FIG. 15 is a block diagram showing an exemplary partial procedure summary 
boundary determined based on the left and right mover status of the actions. 

FIG. 16 is a flowchart showing an exemplary method for identifying actions 
atomically modelable with respect to multithreaded execution of the actions via the 
20 mover status of the actions. 

FIG. 17 is a block diagram showing an exemplary implementation of 
reachability and summarization rules. 

FIG. 18 is a block diagram showing another exemplary implementation of 
reachability and summarization rules. 
25 FIG. 19 is a diagram depicting a general-purpose computing device constituting 

an exemplary system for implementing the disclosed technology. 
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DETAILED DESCRIPTION 

Overview 

In the following description of the disclosed technology, reference is made to 
the accompanying drawings which form a part hereof, and in which is shown by way of 
illustration specific embodiments in which the invention may be practiced. Other 
embodiments may be utilized and structural changes may be made without departing 
from the scope of the disclosed technology. 

Example 1 - Exemplary System for Analyzing Multithreaded Software via Procedure 

Summaries 

FIG. 1 is a block diagram representing an exemplary system 100 for analyzing 
multithreaded software via procedure summaries. In the example, the system takes 
multithreaded software 1 12 as input. A model checker 120 analyzes the multithreaded 
software 112. For example, the model checker 120 can model execution of 
multithreaded software 1 12 to detect programming flaws. 

In practice, the multithreaded software 112 can be first converted into a model 
122, which can represent the multithreaded software 1 12 in a form appropriate to 
facilitate modeling. In the example, the model 122 can include one or more procedure 
summaries 124. 

The model checker 120 can generate results 130. For example, the model 
checker can indicate whether the multithreaded software 112 contains programming 
flaws and information about such flaws. 

Example 2 - Exemplary Method for Analyzing Multithreaded Software with 

Procedure Summaries 
FIG. 2 is a flowchart showing an exemplary method 200 for analyzing 
multithreaded software via procedure summaries, such as with the system shown in 
FIG. 1 . The methods of any of the examples described herein can be performed in 
software executing computer-executable instructions. Such instructions can be stored in 
one or more computer-readable media. 
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At 212, a model of the multithreaded software is built using procedure 
summaries. For example, as described herein, partial procedure summaries can be 
generated for actions within the procedures of the multithreaded software. 

At 222, the model can be checked for programming flaws. For example, as 
5 described herein, execution of the software can be modeled to detect whether any 
specified invariants (e.g., asserts) fail for any execution path of the software. 

In practice, building the model and checking for programming flaws can be 
combined into a single process. For example, the model can be built as the model for 
the software is checked for programming flaws. 

10 

Example 3 - Exemplary Multithreaded Software 
Exemplary multithreaded software includes software that makes use of more 
than one thread during execution of the software. For example, multithreaded software 
can include a scenario where two threads access one or more shared variables. Such 
15 software can include synchronization mechanisms (e.g., locks, mutexes, semaphores 
and the like) to avoid undesirable phenomena such as race conditions for shared 
variables or other conditions associated with execution of concurrent programs. 



Example 4 - Exemplary State 
20 In any of the examples described herein, the state of software can include a wide 

variety of variables. Such variables can include global variables, local variables, or 
some combination thereof. 

Although the state of a program can include the state of a stack, the procedure 
summaries described herein need not take stack state into account. For example, the 
25 state of a stack can be tracked when invoking a procedure, but a stack internal to the 
procedure (e.g., stack frames generated by the procedure) need not be represented 
during modeling. 
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Example 5 - Exemplary Procedures 
In any of the examples described herein, procedures can include any set of 
executable instructions, actions, or operations grouped into an invocable unit, such as a 
procedure or a function. In practice, procedures typically have zero or more parameters, 
5 which can be operate as input parameters, output parameters, or some combination 
thereof. 

Example 6 - Exemplary Programming Flaws 
In any of the examples described herein, analysis of multithreaded software can 
10 include detecting programming flaws of the software. Exemplary programming flaws 
can include a wide variety of conditions, widely referred to as "bugs." To detect 
programming flaws, programmers have developed a variety of mechanisms. 

For example, one such mechanism is a specified invariant. An example 
implementation of a specified invariant is called an "assert." The assert indicates a 
15 condition (i.e., and assertion) that is believed to be invariant at a particular location 
within the software. If the condition is false for any possible set of execution paths, a 
programming flaw is indicated. In such a case, the assert is said to have failed. 

For example, a programmer can include the following assertion in the 
programming code: 
20 assert (pAction != NULL) 

If it is possible that the software can reach the location of the assertion, and pAction is 
NULL (i.e., the assertion is false and the invariant is not correct), the assert has failed. 
Thus, a programming flaw is indicated. 

In practice, the assert can be implemented as a runtime check (e.g., during 
25 debugging), or the assert can be used during modeling of the software. For example, 
the assert mechanism can be used in any of the examples described herein. If it is 
determined that the assert fails during modeling using procedure summaries, a 
programming flaw is indicated. 

Details about the flaw can be produced to aid in debugging the software. For 
30 example, a location of the assert within the software, the current state, and execution 
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history can be indicated by the model checking software. The programmer can use the 
information to determine the cause of the assertion failure. 

Example 7 - Exemplary Model Checker 
FIG. 3 shows an exemplary model checker 310 using procedure summaries for 
analyzing multithreaded software. The model checker 310 can accept multithreaded 
software as input and then generate and analyze a model 330 representing the software. 

In the example, the model checker 310 includes a reachability analyzer 322 and 
a procedure summarizer 332. The reachability analyzer 322 is operable to determine 
the possible execution paths for the multithreaded software, and the possible states of 
the software during such execution paths. The procedure summarizer 332 is operable to 
generate procedure summaries 334 for the multithreaded software as part of the model 
330 of the software. The reachability analyzer 322 can consult the procedure 
summaries 334 during its analysis. 

In the example, the reachability analyzer 322 can model one or more stacks for 
the software. The procedure summaries 334 need not model a stack. Thus, the model 
checker 310 can explore software states with stacks and procedure summaries without 
stacks. As a result, summarization can avoid direct representation of the call stack. 

Example 8 - Exemplary Method for Analyzing Multithreaded Software via 
Reachability Analysis and Procedure Summaries 

FIG. 4 shows an exemplary method 400 using reachability and procedure 
summaries to analyze multithreaded software. 

At 412, reachability analysis of the multithreaded software begins. For example, 
reachability analysis can include modeling execution of the software by determining the 
possible execution paths of software and systematically exploring the state of the 
software during such execution paths. 

At 414, when a procedure is encountered, a summary for the procedure is 
generated. For example, partial procedure summaries can be calculated by software. 
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At 416, the summary is returned for consultation by the reachability analysis. 
The reachability analysis can then continue. For example, the reachability analysis can 
determine possible execution paths within the procedure and use the procedure 
summary to explore possible states. If the procedure is encountered again during 
5 reachability analysis, the procedure summary can be reused rather than re-generated. 

Example 9 - Exemplary Partial Procedure Summaries 
In any of the examples, a procedure can be summarized by a plurality of partial 
procedure summaries. Partial procedure summaries can resemble procedure summaries 
10 and can have the same properties. However, partial procedure summaries can be used 
to accurately model multithreaded software. 

FIG. 5 shows an exemplary arrangement 500 in which a plurality of partial 
summaries 530A-530N have been generated for a procedure 512. The partial procedure 
summaries 530A-530N can summarize less than all of the procedure 512 (e.g., 
15 summarize up to a location in the middle of the procedure 512, rather than summarizing 
from beginning to end). 

In combination, the partial procedure summaries 530A-530N can model 
execution of the entire procedure and accurately model state of the software 512 during 
multithreaded execution, even if the procedure 512 is subject to interruption by other 
20 threads. 

Example 10- Exemplary Method for Generating Partial Procedure Summaries 
FIG. 6 shows an exemplary method 600 for generating partial procedure 
summaries, such as those shown in FIG. 5. 
25 At 610, procedure code is received (e.g., by a procedure summarizer). The code 

can take the form of source code or object code. 

At 620, a plurality of partial procedure summaries operable to model 
multithreaded execution of the procedure are generated. For example, the partial 
procedure summaries can accurately model the state of the software, even if the 
30 procedure is subject to interruption by other threads. 
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In practice, some procedures of multithreaded software can be summarized 
without resorting to partial procedure summaries. 

Example 11 - Exemplary Procedure Actions 
5 FIG. 7 illustrates exemplary actions for a procedure having procedure code 710. 

In the example, the procedure code 710 comprises a plurality of statements. When the 
statements are executed, the execution can result in any of the one or more series of 
actions 720A-720N by the procedure, after which the procedure can terminate. The 
actions can affect the initial state of the software, leaving the software in a resulting 
10 state. 

As shown in the example, the actions may differ depending on the entry state for 
the procedure code 710. For example, execution may take different paths depending on 
the value of various variables. A partial procedure summary can summarize less than 
all of the actions for a particular entry state (e.g., less than all the actions 720A). A 
15 plurality of partial procedure summaries can be generated for any one or more of the 
series of actions 720A-720N. 

Example 12 - Exemplary Partial Procedure Summaries 

FIG. 8 shows exemplary partial procedure summaries based on a series of 
20 actions of a procedure. In the example, a series of actions 812 of a procedure has been 
divided into two or more subsets of actions 820A-820N. In the example, the subsets of 
actions are atomically modelable with respect to multithreaded execution of the 
procedure. 

Atomic modelability can include the property that the actions can be modeled 
25 together without regard to possible interleaved actions from other threads. The actions 
can be deemed to have occurred one after the other without interruption by other 
threads. For example, a set of actions that are atomically modelable may be executable 
as a set. Regardless of whether actions from other threads execute during execution of 
the set, the resulting state will be the same. The software state can thus be accurately 
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modeled by a procedure summary constructed from such actions even if the procedure 
is subject to interruption by other threads. 

Based on the respective subsets of actions 820A-820N, respective partial 
procedure summaries 830A-830N can be generated. For example, the partial summary 
830A can model the changes in state caused by execution of the actions 820A, and so 
on. 

Example 13 - Exemplary Modeling as Transactions 
Based on the atomic modelability of a set of actions, the execution of a thread 
can be represented as a series of transactions. A transaction can be a series of actions 
which appear to execute atomically (e.g., performed until completion without 
interruption) to other threads. In some cases, a procedure can be summarized as a 
single transaction. 

Example 14 - Exemplary Method for Generating a Partial Procedure Summary 

FIG. 9 shows an exemplary method 900 for generating a partial procedure 
summary. At 910, a plurality of actions of the procedure that are atomically modelable 
with respect to multithreaded execution of the software are identified. 

At 920, a procedure summary of the procedure is generated based on the 
plurality of atomically modelable actions. For example, a partial summary of the 
procedure can be generated. 

Example 15 - Exemplary Partial Procedure Summary Boundaries 

FIG. 10 shows an arrangement 1000 including the actions 1012 for a procedure 
to be summarized. In the example, the actions 1012 have been divided into two or more 
sets 1020A-1020C of successive actions based on the respective one or more boundaries 
1030A-1030B. 

As described herein, the boundaries 1030A-1030B can be chosen so that the 

procedure summaries accurately model the state of the software when executed in 

during multithreaded execution of the software (e.g., if the procedure 512 is subject to 
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interruption by other threads). For example, boundaries can be chosen based on 
whether the sets of actions are atomically modelable with respect to multithreaded 
execution of the procedure actions. Boundaries can also be chosen based on 
transactions boundaries within the actions 

5 

Example 16- Exemplary Method for Determining Boundaries for Partial Procedure 

Summaries 

FIG. 1 1 shows an exemplary method 1 100 for identifying partial procedure 
boundaries. 

10 At 1 100, transactions (e.g., sets of actions atomically modelable with respect to 

multithreaded execution of the software) within actions of a procedure are identified. 
At 1 1 14, the transaction boundaries are used for partial procedure summary boundaries. 
For example, a partial procedure summary can be generated from the actions within the 
transaction. 

15 

Example 17- Exemplary Inclusion of Procedure Location in Summary 

In any of the examples described herein, a procedure summary can include one 
or more indications of a location within the procedure. For example, the procedure 
summary can indicate an initial location and a resulting location in the procedure. In 

20 such a case, the summary summarizes actions for the procedure starting at the initial 

location and ending at the resulting location. In some cases, execution may loop, so it is 
possible for a resulting location to be before the initial location in the code. Such 
locations are sometimes called the "program counter" because they reflect a modeled 
value of a program counter executing the procedure. 

25 Inclusion of the initial and resulting locations can help in piecing together partial 

summaries. In such a case, the initial and resulting locations may not correspond to the 

beginning or end of the procedure being summarized. 

The program counter need not be stored separately from the state. For example, 

the program counter can be considered part of the state of the software (e.g., where 

30 within the procedure the program counter points). 
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Example 18 - Exemplary Procedure Summary Format 

A variety of formats can be used to represent a procedure summary (e.g., having 
the partial procedure summaries 530A-530N of FIG. 5) of multithreaded software. Any 
5 of the formats can be stored as a data structure on one or more computer readable 
media. 

FIG. 12 shows an exemplary format 1200 for a procedure summary 1220. In the 
example, one or more state pairs 1230A-1230N are stored for the summary 1220. For a 
respective state pair (e.g., consider the state pair 1230A), an initial state 1231 A and a 
10 resulting state 1235 A can be stored. In addition, a starting program counter location 
1232A can be stored for the initial state 1231 A, and a resulting program counter 
location 1236 A can be stored for the resulting state 123 5 A. 

The state pair 1230A can be used to model execution for the procedure. If the 
modeled state of the software is the initial state 1231 A at location 1232 A within the 
15 procedure, then the state (or one of the possible states) of the software after execution of 
the modeled procedure or portion thereof will be the resulting state 1235 A at location 
1236A. Execution may continue within the procedure and be modeled by another state 
pair within the procedure summary 1220. 

The procedure summary 1220 can include a plurality of partial procedure 
20 summaries summarizing different sets of actions for the procedure. A partial procedure 
summary for the same set of actions can include a plurality of state pairs to represent a 
plurality of initial states, a plurality of resulting states, or some combination thereof. 
However, in some cases, the procedure summary can summarize the entire procedure 
via a single state pair. 

25 The procedure actions represented by a state pair can be determined according to 

any of the techniques described herein. For example, a plurality of actions atomically 
modelable with respect to multithreaded execution of the software can be identified. 
Boundaries between procedure actions can be chosen based on transaction boundaries 
as described herein. 

30 
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Example 19- Exemplary Atomic Modelability 
In any of the examples described herein, partial procedure summaries of a 
procedure of multithreaded software can be constructed from a set of actions in a 
procedure that are atomically modelable with respect to multithreaded execution of the 
software. 

Example 20 - Exemplary Efficiency via Partial Procedure Summaries 

Procedure summaries result in more efficient analysis of software due to the 
phenomenon of summarization. Summarization can be applied as a technique to reduce 
the amount of computation needed to model execution of software. For example, a 
procedure summary may reflect a complex series of many actions in a procedure as a 
simple transition from one state to another. 

Thus, as the number of actions modeled by the summary increases, the 
efficiency of the modeling process also increases. 

Those actions identified as atomically modelable can be modeled by a single 
procedure summary. Thus, as the number of actions identified as atomically modelable 
increases, the efficiency of the modeling process can also increase. Such efficiency can 
result in increased scalability. 

Example 21 - Using Reduction (Movers) to Group Actions 

In any of the examples described herein, a technique sometimes called 

"reduction" can be used when grouping actions into transactions. The technique is 

useful because it can be used to increase the number of actions represented in a 

transaction, resulting in a smaller number of transactions. As a result, the modeling 

techniques are more scalable (e.g., can be applied to larger programs). 

FIG. 13 shows an exemplary arrangement 1300 involving right and left movers. 

Right movers are actions that can be commuted to the right (e.g., moved later in time) 

of any action of another thread without affecting the resulting state. Thus, during 

modeling, the right mover can be modeled as occurring after any action of another 

thread. Conversely, left movers are actions that can be commuted to the left (e.g., 
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moved earlier in time) of any action of another thread without affecting the resulting 
state. Thus, during modeling, the left mover can be modeled as occurring before any 
action of another thread. 

In the example, a set of actions 13 10A for a plurality of threads is shown. A 
first thread executes the actions right mover 1320A, action 1330A, left mover 1340A, 
and left mover 1340B. One or more other threads execute the actions Ej 1350A, E 2 
1350B, and E3 1350C. In the example, the right mover action 1320 has been identified 
(e.g., by software) as a right mover, and the left mover actions 1340A and 1340B have 
been identified (e.g., by software) as left movers. 

Based on applying the technique of right and left movers, when the actions are 
modeled, the right mover 1320A can be moved to the right of any action of any other 
thread until it abuts the action 1330A. Conversely, the left mover actions 1340A and 
1340B can be moved to the left of any action of any other thread until they abut the 
action 1330A. As a result, the multithreaded execution of the actions shown in 1310A 
can be modeled as the actions shown in 131 0B while still accurately modeling the 
resulting state of the software when executed in a multithreaded scenario. Accordingly, 
the actions 1320A, 1330A, 1340A, and 1340B are atomically modelable with respect to 
multithreaded execution of the software. 

Thus choosing partial procedure boundaries for groups of actions atomically 
modelable with respect to multithreaded execution of the software can be based at least 
on the right mover and left mover status of the actions. 

For example, for purposes of the procedure summaries, a set of actions 
atomically modelable with respect to multithreaded execution of the software can be 
determined using the arrangement 1400 shown in FIG. 1400. 

In the example, a set of actions 1410 atomically modelable with respect to 
multithreaded execution of the software is found by identifying a set of zero or more 
right movers 1420A-1420N, followed by an action 1430A (e.g., which itself may be a 
right or left mover), followed by zero or more left movers 1440A-1440N. In practice, 
as shown, a plurality of right movers and a plurality of left movers may be included. 
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If the set of actions 1410 is modeled as a transaction, determining the transaction 
boundaries can be determined as shown. For example, FIG. 15 shows an arrangement 
1500 in which a transaction boundary 1530 has been found based on left and right 
mover status of the actions. In the example, two transactions were identified. The first 
transaction 1520A comprises three right movers, an action, and two left movers, the 
next transaction 1520B comprises a right mover followed by other actions. Additional 
boundaries are possible (e.g., following the boundary 1530). 

Example 22 - Exemplary Mover Status 
The mover status for certain actions is easily determined. For example, the 
action acquire (m) , where m is a mutex, is a right mover. Once it happens, there is 
no enabled action of another thread that may access m. Hence, the action can be 
commuted to the right of any action of another thread. The action release (m) is a 
left mover. At a point where it is enabled but has not happened, there is no enabled 
action of another thread that may access m. Hence, this action can be commuted to the 
left of any action of another thread. 

Any action that accesses only local variables or shared variables protected by 
locks during the action is both a left mover and a right mover, since such action can be 
commuted both to the left and to the right of actions by other threads. Any action that 
accesses a shared variable is both a left mover and a right mover, as long as the threads 
acquire a fixed mutex before accessing the variable. 

Example 23 - Exemplary Method for Grouping Actions Based on Mover Status 
FIG. 16 shows an exemplary method 1600 for identifying actions atomically 
modelable with respect to multithreaded execution of the actions via the mover status of 
the actions. For example, the method 1600 can be used to implement box 910 of FIG. 
9. 

At 1610, the mover status of the actions is identified. Software can analyze the 
actions to determine if they are left or right movers. In some cases, an action may be 
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neither a left or right mover. Additionally, an action can be both a left and a right 
mover. 

At 1620, the actions are grouped based on boundaries between the transactions 
indicated by the left and right movers. For example, when a right mover follows a left 
5 mover, a boundary between the two is indicated. Such actions within the boundaries are 
atomically modelable with respect to the multithreaded execution of the procedure 
having the actions. 



Example 24 - Exemplary Phase Variable 
10 A transaction can be defined as a sequence of right movers, followed by a single 

atomic action, followed by a sequence of left movers. A transaction can be tracked by 
using two states: pre-commit or post-commit. A transaction starts in the pre-commit 
state and stays in the pre-commit state as long as right movers are being executed. 

In order to track the phase of a thread's transaction when execution of the thread 
15 is modeled, a modeled variable local to the procedure can be stored. Such a variable 
can be called a phase variable. For example, the phase variable can reflect that the 
thread is in the pre-commit or post-commit part of a transaction. 

A thread can be considered to be in the pre-commit part of the transaction as 
long as it is executing right movers. After the atomic action (with no restrictions) is 
20 executed, the transaction can move to the post-commit state. The transaction stays in 
the post-commit state as long as left movers are being executed until the transactaion 
completes. 

The phase variable can be implemented as a Boolean variable, indicating True 
for pre-commit and False otherwise. The variable can then be watched. When it moves 
25 from True to False, a transaction boundary is indicated. Such a boundary can be used 
when identifying the actions atomically modelable with respect to multithreaded 
execution of the software. 
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Example 25 - Exemplary Use of Flaw Indicated Variable 
In order to track when a programming flaw has been detected by the modeling 
software, a variable local to the thread (e.g., "wrong") can track whenever an assertion 
fails. After the assertion fails, the failing thread can be prevented from making any 
5 other transitions (e.g., modeled execution for the thread stops). 

Example 26 - Exemplary Procedure Summary 

Procedure summaries can reflect that when a given procedure is called in some 
state 5, the procedure exits in a state s*. A procedure summary can be a collection of the 
10 possibilities that can occur given a procedure, possible input(s), and possible output(s). 
The use of procedure summaries provides reuse and avoids wasteful computation. 
Consider the following procedure P: 

add(int x, int y) { 
int z ; 

15 z = x + x; 

z = z + 2y; 
return z; 

} 

If the procedure P is called with x = 1 and y = 2, then the procedure P will exit by 
20 returning z = 6. In other words, an entry of a procedure summary for P where x = 1 
and y = 2 could be specified as (1, 2, 6). An entry of the procedure summary for P 
where x = 2 and y = 1 could be specified as (2, 1, 6), and so on. 

Example 27 -Sample Case 1 of a Summarization-Based Model Checking Technique 
25 The following four sample cases illustrate different approaches for performing 

model checking. A model checker can implement any combination of the sample cases. 
The first case illustrates a simple case where the transaction boundary and the procedure 
boundary coincide. Consider the following resource allocation routine: 
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bool available [N] ; 
mutex m; 

int getResource () { 
int i = 0; 
acquire (m) ; 
while (i < N) { 

if (available til) { 
available [i] = false; 
release (m) ; 
return i; 

} 

L6: i++; 

} 

L7 : release (m) ; 
15 L8 : return i ; 

} 

There are N shared resources numbered 0, . . . , N -1 . The j -th entry in the global 
Boolean array available is true iff the j -th resource is free to be allocated. A mutex m is 
used to protect accesses to available. The mutex m has the value 0 when free, and 1 

20 when locked. The body of getResource acquires the mutex m, and then searches for 
the first available resource. If a free resource is found at index i, it sets 
available [i] to false and releases the mutex. If no free resource is found, then it 
releases the mutex. In both cases, it returns the final value of i. Thus, the returned 
value is the index of a free resource if one is available; otherwise, it is N. There is a 

25 companion procedure f reeResource for freeing an allocated resource (not shown 
above). Multithreaded programs might include a number of threads that non- 
deterministically call getResource and f reeResource. 

Since acquire (m) is a right mover, release (m) is a left mover, and all 
other actions in getResource are both right and left movers, the entire procedure is 

30 contained in a single transaction. Suppose N = 2 and (a 0 ' , ai ' ) denotes the contents of 

available, where a 0 and a x denote the values of available [0] and 

available [1] , respectively. The summary of getResource consists of a set of 

edges of the form (pc, i, m, (a 0 , a 1 ))h->(pc', i\m', (a 0 \ ax')), where the tuple (pc, 
i, m, (a 0 , ai)) represents the values of the program counter and variables i, m, and 
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available in the pre-store of the transaction and the tuple (pc', i',m', (a 0 \ a^)) 

denotes the corresponding values in the post-store of the transaction. The computed 

summary of getResource consists of the following edges: 

(L0,0,0, (0, 0»H>(L8,2, 0, (0, 0)) 
(LO, 0,0, <0,1))h>(L5,1,0, (0, 0» 
(LO,0,0,(1,0))^(L5,0, 0, (0, 0)) 
(L0,0,0,(1,1))H>(L5,0, 0,(0,1)) 

All of the edges in this summary begin at the label L0 and terminate at one of 
two labels (L8 or L5), both of which are labels at which getResource returns. Thus, 
the summary matches the intuition that the procedure body is just one transaction. The 
first edge summarizes the case when no resource is allocated; the remaining three edges 
summarize the case when some resource is allocated. There is no edge beginning in a 
state with m = 1 since, from such a state, the execution of the transaction blocks. Once 
this summary has been computed, if any thread calls getResource, the summary can 
be used to compute the state at the end of the transaction, without reanalyzing the body 
of getResource, thus providing reuse and scalability. 

Example 28 - Sample Case 2 of a Summarization-Based Model Checking Technique 

The second case illustrates summarization where a procedure body contains 
several transactions inside of it. Consider the following modified version of the 
resource allocator of Case 1 : 
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bool available [N] ; 
mutex m; 

int getResource () { 

int i = 0; 
L0: while (i < N) { 
LI : acquire (m [i] ) ; 

L2: if (available [i] ) { 

L3 : available [i] = false; 

L4 : release (m [i] ) ; 

L5 : return i; 

} else { 
L6 : release m [i] / 

} 

L7 : i++; 

} 

L8 : return i; 
} 

The locking has been made more fine-grained through the use of an array m of mutexes 
and by protecting the j -th entry in avai lable with the j -th entry in m. Now, the 
body of the procedure getResource is no longer contained entirely in a single 
transaction. In fact, there is one transaction corresponding to each iteration of the loop 
inside of it. Again, suppose N = 2. Now the summary contains edges of the form (pc, 

i, (m 0 , mi), (a 0 , ai))h->(pc', i', (m 0 \ mi'), (a 0 \ ai')), where (m 0 , mx) denotes the 

contents of m in the pre-store and (m 0 \ mi ' ) denotes the contents of m in the post-store. 

The computed summary of getResource consists of the following edges: 

(LO, 0, (0, 0), (0, 0)) H> (LI, 1, (0, 0), (0, 0)) 
(L0, 0, (0, 0), (0, 1)) H> (LI, 1, (0, 0), (0, 1)) 
(LO, 0, (0, 0), (1, 0)) H> (L5, 0, (0, 0), (0, 0)) 
(LO, 0, (0, 0), (1, 1» H> (L5, 0, (0, 0), (0, 1)) 

(LI, 1, (0, 0), (0, 0)) H> (L8, 2, (0, 0), (0, 0)) 
(LI, 1, (0, 0), (0, 1)) K> (L5, 1, (0, 0), (0, 0)) 
(LI, 1, (0, 0), (1, 0)) h> (L8, 2, (0, 0), (1, 0)) 
(LI, 1, (0, 0), (1, 1)) H> (L5, 1, (0, 0), (1, 0)) 

This summary contains three kinds of edges. The first two edges correspond to 
the transaction that starts at the beginning of the procedure, i.e., at label L0 with i = 0, 
goes through the loop once, and ends at LI with i = 1 . The next two edges correspond 
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to the transaction that again starts at the beginning of the procedure, but ends with the 
return at label L5 during the first iteration through the loop. The last four edges 
correspond to the transaction that starts in the middle of the procedure at label LI with 
i = 1, and returns either at label L5 or L8. The edges of the first and third kind did not 
exist in the summary of the previous version of getResource, where all edges went 
from entry to exit. 

Example 29 - Sample Case 3 of a Summarization-Based Model Checking Technique 
The third case illustrates that the analysis can terminate and validate the program 
assertions even in the presence of unbounded recursion. Consider the following: 

int g = 0; 
mutex m; 



void 


foo(int r) { 


void main() { 


L0: 


if (r == 0) { 




int q = choose ( {0 , l} ) 


LI: 


foo(r) ; 


M0: 


foo(q) ; 




} else { 


Ml: 


acquire (m) ; 


L2: 


acquire (m) ; 


M2 : 


assert (g >= 1) ; 


L3 : 


g++; 


M3: 


release (m) ; 


L4 : 


release (m) ; 


M4: 


return; 




} 


} 




L5: 


return; 







} 



P = { main() } | | { main() } 

Program P consists of two threads, each of which starts execution by calling the 
main procedure. The main procedure has a local variable q which is initialized non- 
deterministically. Then main calls f oo with q as the actual parameter. The procedure 
f oo has an infinite recursion if the parameter r is 0. Otherwise, it increments global g 
and returns. After returning from f oo, the main procedure asserts that (g >= 1). All 
accesses to the shared global g are protected by a mutex m. The initial value of g is 0. 

The stack can grow without bound due to the recursion in procedure f oo. 
Hence, naive model checking does not terminate on this case. However, the body of 
f oo consists of one transaction, since all action sequences in f oo consist of a sequence 
of right movers followed by a sequence of left movers. A summary edge for f oo is of 
the form (pc, r, m, g) h-> (pc ' , r ' , m ' , g ' ), whose meaning is similar to that of a 
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summary edge in the previous cases. The summary for f oo consists of the following 
edges: 

(L0, 1,0, 0)H>(L5, 1,0,1) 
(LO, 1,0, 1)H>(L5, 1,0,2) 

There is no edge beginning in a state with r = 0 since, from such a state, the execution 
of the transaction never terminates. Using summaries, reasoning about the stack 
explicitly inside of f oo and exploring the unbounded recursion in f oo are both 
avoided. 

The body of main has two transactions. The first transaction begins at label M0 
and ends at label Ml, consisting primarily of the call to f oo. The second transaction 
begins at label Ml and ends at label M4. A summary edge for main has the form (pc, 
q, m, g) h-> (pc ' , q ' , m' , g '). The summary for main consists of the following edges: 

(M0, 1,0, 0)H>(M1, 1,0, 1) 
(M0, 1, 0, 1) h-» (Ml, 1,0, 2) 

(MO, 1,0,1) H»(M4, 1,0,1) 
(MO, 1,0, 2)h+(M4, 1,0, 2) 

Using the above summaries for procedures f oo and main, the model checking 
analysis is able to terminate and correctly conclude that P is free of assertion violations. 
The analysis can begin with an empty stack for each thread. When a thread calls main, 
since the body of main is not contained within one transaction, the analysis pushes a 
frame for main on the stack of the calling thread. However, when a thread calls f oo, 
no frame corresponding to f oo is pushed since the entire body of f oo is contained 
within a transaction. Instead, f oo is summarized and its summary is used to assist with 
the model checking. 

Example 30 - Sample Case 4 of a Summarization-Based Model Checking Technique 

The fourth case illustrates a summarization technique for a procedure that is 
called from different transactional contexts. Consider the following: 
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int gm = 0, gn = 0; 

mutex m, n; 

void bar () { 

NO : acquire (m) ; 

Nl : gm++; 

N2 : release (m) ; 

} 



void 


foolO { 


void 


foo2() { 


L0: 


acquire (n) ; 


M0: 


acquire (n) ; 


LI: 


gn++; 


Ml: 


gn++; 


L2 : 


bar() ; 


M2: 


release (n) ; 


L3 : 


release (n) ; 


M3: 


bar() ; 


L4 : 


return; 


M4 : 


return; 


} 




} 





P = { foolO } | | { foo2() } 

Two shared variables, gm and gn, are protected by mutexes m and n, 
respectively. Procedure bar accesses the variable gm, and is called from two different 
procedures fool and f oo2. In fool, the procedure bar is called from the pre- 
commit state of the transaction, since no mutexes are released prior to calling bar. In 
f oo2, the procedure bar is called from the post-commit state of the transaction, since 
mutex n is released prior to calling bar. The summary for bar needs to distinguish 
these two calling contexts. In the case of the call from fool, the entire body of fool, 
including the call to bar, is part of the same transaction. In the case of the call from 
f oo2, there are two transactions, one from label M0 to M3, and another from label M3 
to M4. These two calling contexts are distinguished by instrumenting the semantics of 
the program with an extra bit of information that records the phase of the transaction. 
Then, each summary edge provides the pre- and post- values not only of program 
variables but also of the transaction phase. 

Example 31 - Exemplary Analysis of Store of a Multithreaded Program 
For purposes of illustration, the store of a multithreaded program is partitioned 
into the global store Global and the local store Local of each thread (see Table 1). The 
set Local of local stores has a special store called wrong. The local store of a thread 
moves to wrong on failing an assertion and thereafter the failed thread does not make 
any other transitions. 
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Table 1 - Domains of a Multithreaded Program 



t, U € 


Tid 


= (I n\ 


g e 


Global 




/ e 


Local 




Is e 


Locals 


= 7zd — > Zoca/ 


/ 6 


Frame 




5 <E 


Stack 


= Frame* 




Stacks 


= Tid ^ Stack 


State 




Global x Locals x Stacks 



A multithreaded program (ga, Zs 0 , 7, r + , T") consists of five components, go is 
the initial value of the global store. ls 0 maps each thread id / e Tid to the initial local 
5 store lso(t) of thread t. The behavior of the individual threads may be modeled through 
use of the following three relations: 

T c Tid x (Global x Loca/) x (Gfofo/ x Local) 
T + c; 7jW x Zoca/ x (Local x Frame) 
T~ c; 7YJ x (Local x Frame) x Zoca/ 
10 The relation 7 models thread steps that do not manipulate the stack. The relation T(t 9 g, 
/, g', /") holds if thread / can take a step from a state with global store g and local store /, 
yielding (possibly modified) stores g' and /'. The stack is not accessed or updated 
during this step. The relation T + (t, /, l\f) models steps of thread t that push a frame 
onto the stack. Similarly, the relation T ~(t, l 9 f 9 1") models steps of thread t that pop a 
15 frame from the stack. This step also does not access the global store, is enabled when 
the local store is /, updates the local store to /', and pops the frame / from the stack. 

The program starts execution from the state (g 0 , ho, sso) where ss 0 (t) = e for all t 

e Tid. At each step, any thread may make a transition. The transition relation — >/ e 

State x State of thread / is defined below. For any function h from A to B y a e A and b 
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s B, h[a := b] denotes a new function such that h[a := 6](x) evaluates to h(x) ifx^a, 
and to b if x = a. 

Table 2 - Transition relation _^. ( 

r(/,g,fe(0,g',/') 
T+(tMt)J',f) 

(g,ls,ss)-+ t (g,b[t := l'\ss[t := ss(t),f]j 

ss(t)=s.f T-(tMt),fJ') 
(gjs^^igjsit^l'lssit^s]} 

The transition relation — > c State x State of the program is the disjunction of the 
transition relations of the various threads. 

-+ = 3/. ^ t 

Example 32 - Exemplary Transaction using the Theory of Movers 
Referring back to FIG. 13, particular actions can be used to illustrate the theory 
of movers. Suppose a thread performs the following sequence of four operations: (1) 
acquires a lock (1320A is an acq operation), (2) reads a variable x protected by that 
lock into a local variable t (1330A is the action t = x), (3) updates the variable 
(1340A is the action x = t + 1), and (4) releases the lock (1340B is the action rel). 
Suppose that the actions of this method are interleaved with arbitrary actions Ej 1350A, 
E2 1350B, E3 1350C of other threads. It is assumed that the environment actions respect 
the locking discipline of accessing x only after acquiring the lock. 
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As discussed above, the acquire operation is a right mover. Therefore, it can be 
commuted to the right of the environment action Ej without changing the final state S3, 
even though the intermediate state changes from s 2 to 52'- Similarly, the write and 
release operations are left movers and are commuted to the left of environment actions 
5 E 2 and E3. Finally, after performing a series of commute operations, the execution at 
the bottom of the diagram occurs, in which the actions of the first thread happen without 
interruption from the environment. Note that in this execution the initial and final states 
are the same as before. Thus, the sequence of operations performed by the first thread 
constitutes a transaction. The transaction is in the pre-commit state before the action 
10 1330A and in the post-commit state afterwards. 

Example 33 - Exemplary Model Checking with Reduction 
Consider a situation where RM, LM<z, Tare subsets of a transition relation T 

with the following two properties for all / ^ u: 

15 1 . If RM(t, g h //, g 2 , h) and T(u, g 2 , h, gj, h\ there is g 4 such that T{u, g h l 3 , g 4 , 

U) and RM(u, g h l 3 , g 4 , U\ Further, RM(u, g 2> l 3 , g 3 , U) iff RM(u, g h l 3 , g 4 , 
l 4 ), and LM(u, g 2 , g3, U) iff LAf(u 9 gj, l 3 , g4, Id- 
2. If r(w, g u //, g2, h) and LM(t, g 2 , l 3 , g3, h\ there is g 4 such that LM(t, g h l 3 , 
g 4 , l 4 ) and T(u 9 g 4 , l h g 3 , l 2 ). Further, RM(u, g h l h g h l 2 ) iff RM{u, g 4> l u g3, 
20 l 2 ) 9 and LM(u, g h l h g 2 , l 2 ) iff LM(u, g 4 , l h g 3 , l 2 ). 

The first property states that a right mover action in thread t commutes to the right of an 
action of a different thread w. Moreover, the action by thread u is a right mover 
(respectively for left movers) before the commute operation iff it is a right mover 
(respectively for left movers) after the commute operation. Similarly, the second 
25 property states the requirement on a left mover in thread /. This analysis is 

parameterized by the values of RM and LM and only requires that they satisfy these two 
properties. The larger the relations RM and LM, the longer the transactions this analysis 
infers. Therefore, these relations should be as large as possible in practice. 
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As discussed previously, a transaction is a sequence of right movers followed by 
a single action followed by a sequence of left movers. In order to minimize the number 
of explored interleavings and the maximize reuse, transactions that are as long as 
possible should be inferred. In order to implement this inference, a Boolean local 
variable should be introduced in each thread to keep track of the phase of that thread ! s 
transaction. Note that this instrumentation is done automatically by the analysis (and 
thus not by the programmer). The phase variable of thread t is true if thread / is in the 
right mover (or pre-commit) part of the transaction; otherwise the phase variable is 
false. In other words, the transaction commits when the phase variable moves from true 
to false. The initial value of the phase variable for each thread is true. 
p,p' € Boolean 

/, /' € Local = Local x Boolean 
Is, Is' e Locals 1 = Tid Locaf 

The initial value of the global store of the instrumented program remains g 0 . The initial 
value of the local stores changes to ls 0 , where ls 0 (t) = {lso (i), true) for all t e Tid. The 

transition relation T, T + , T' is instrumented to generate new transition relations U, U + , 
U~ that update the phase appropriately. 

U c Tid x (Global x Locaf) x (Global x Locaf) 

U + c Tid x Locaf x (Locaf x Frame) 

U~ e Tid x (Locaf x Frame) x Locaf 
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u(t,g,(i,p),g',(r, P ')) m 

A T{t,g,l,g',l') 

a p' = {RM{t,g,l,g',Vy{pv^LM{t,g,l,g',l'))) 

U + {t,{Lp),{l\p'\f) dgf 
a 7* + (/,/,/',/) 

A //=/> 



c/-0,(/,p) ) /,(/' 5jP ')) dtf 

A T -(/,/,/,/') 

A /?' =p 



15 In the definition of U, the relation between and p reflects the intuition that if p 

is true, then p' continues to be true as long as it executes right mover actions. The phase 
changes to false as soon as the thread executes an action that is not a right mover. 
Thereafter, it remains false as long as the thread executes left movers. Then, it becomes 
true again as soon as the thread executes an action that is a right mover and not a left 

20 mover. 
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Table 3 - Ruleset 1: Model checking with reduction 

(INIT) 

£(g 0 ,/s 0 ,w 0 ) 

(STEP) 
Vm *t.N(u.gJs(u)) 

Y,(glsss) U(t,g,ls(t\g',l') 
Z(g',ls[t:=l'\ss) 

(PUSH) 
Vm ±t.N(u,g,ls(u)) 
^jgMss) u + {tMt),l',f) 

(POP) 
Vu*t.N(»>gMu)) 
Xfe.fe.^) U-(tMt)*f,l') ss(t) = s.f 
Y,(gJs[t:=r\ss[t:=s]} 



5 For each thread t, three sets are defined: 

K(t),£(t),N(t) c Global* Local* 

These sets respectively define when a thread is executing in the right mover part of a 
transaction, the left mover part of a transaction, and outside any transaction. For 
example, in the execution of FIG. 1, let t be the identifier of the thread executing the 
10 transaction. Then, the states {s 2 ,s 3 }e R(t),(s 4 ,s 5 ,s 6 ,s 1 )s L(t), and{s,,.s g }e /V(r). 

These three sets can be any partition of (Global x Locaf) satisfying the following two 
conditions: 

CI. R(t) c {{g, (I, p))\U {ls 0 {t\ wrong} a p\ 
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C2. L{t) C 



(Ui-p)) 



I £ {ls Q (t\wrong}A-ip a 
Vg\l'.T(t,gJ 9 g' 9 r) 
=>LM(t 9 g 9 l 9 g',l 9 ) 



Condition CI says that thread / is in the right mover part of a transaction only if the 
local store of t is neither its initial value nor wrong and the phase variable is true. 
Condition C2 says that thread t is in the left mover part of a transaction only if the local 
5 store of / is neither its initial value nor wrong, the phase variable is false, and all 

possible enabled transitions are left movers. Since (7£(0, £(t) 9 M0) * s a partition of 

{Global x Local\ once lZ(t) and C(i) have been picked according to CI and C2, the set 

M{i) is implicitly defined. 

TZ(t 9 g, I) is written whenever (g, I) e TZ(t), £ (t 9 g, I) whenever (g,l) s £(t) y and 

10 Af(t, g, I) whenever (g, I) e N{t). Finally, using the values of N(i) for all t e Tid, the 

multithreaded program is model checked by computation of the least fixpoint of the set 
of rules in Ruleset 1. The model checking analysis schedules a thread only when no 
other thread is executing inside a transaction. 

In the example, Conditions CI and C2 are not quite enough for the model 
15 checking analysis to account for some scenarios. If a transaction in thread t commits but 
never finishes, the shared variables modified by this transaction become visible to other 
threads. However, the analysis does not explore transitions of other threads from any 
state after the transaction commits. Therefore, a third condition C3 is added which 
states that every committed transaction must finish. In order to state this condition 

20 formally, the transition relation — discussed above is extended to the program store 
augmented with the phase variable in the natural way. 

C3. Suppose (gJ)e L(t), T,(g,ls,ss) and ls(t) = /. 

Then, there is g'Js' and ss' such that (g\ls\t))e 
* 

N(t) and (g,ls,ss)^>t(g',ls',ss'). 
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The analysis is correct for any partition (7l(t), C(t), Af(t)) of (Global x Locaf) satisfying 

conditions CI, C2, and C3. The smaller the value of Hit), the larger the transactions 

inferred by the analysis. Therefore, an implementation of the analysis should pick a 
value for Af(t) that is as small as possible. 

5 The following is a soundness theorem for the disclosed model checking 

analysis: 

Theorem 1: Let (g 0 , lso, U, U + ,U~) be the instrumented multithreaded program. Let Z 
be the least fixpoint of the rules in Ruleset 1. Let the conditions CI, C2, and C3 be 

satisfied. If (go, lso, ss 0 ) —** (g, Is, ss) and ls(i) = wrong, then there is (g\ ls\ ss*) and p 
10 such that Is ', ss 0 and Is '(f) = (wrong, p) . 

Proof: Suppose (go, lso, sso) — (g, Is, ss) through some sequence of actions of various 

threads and ls(t) = wrong. First, the sequence is extended to complete all committed but 
unfinished transactions using condition C3. Then, one by one, each action in an 
uncommitted transaction is commuted to the right and dropped. Eventually, an 

15 execution sequence a with only completed transactions and with the property that a 
goes wrong if the original sequence goes wrong is obtained. Therefore, a goes wrong 
as well. In a, the transactions of a thread could have interleaved actions of another 
thread. The order in which transactions commit is a total order on the transactions in a. 

This total order is denoted by <. a can be transformed into an equivalent execution a* 

20 (by appropriately right-commuting right movers and left-commuting left movers), such 
that a 1 has the following properties: (1) for every thread t, no action of a different thread 

V occurs in the middle of a transaction of thread /, (2) the transactions in o y commit in 
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the order <. From the properties of right and left movers, it can be determined that a' 

also goes wrong. Since a' schedules each transaction to completion, the states along a' 
will be explored by the rules in Ruleset 1. 

5 Table 4 - Ruleset 2: Level I Reachability 



(INIT) 



(STEP) 

Q(g, Is, ss) Vw * t. N(u, g, &(«)) 

Sum{t,gMt),g',l') 
Q(g',ls[t:=l'\ss,ps[t:=p']j 



(PUSH) 

Q{g, Is, ss) Vu*t.N{u,g,ls{uj) 
Sum + {t,g,ls{t),g',V,f) 
n{g',ls[t:=l'\ss[t:=ss(t),f]) 

(POP) 

Q(g,ls,ss) V« * t. N(u,g,ls(u)) 
ss(t) = s.f Sum-(t,g,ls(t),f,g',l') 
n(g',ls[t:=l'\ss[t.= s]) 

(CFL START) 

fl(g, Is, ss) \/u * t. N(u, g, ls(uj) 

P{t,gM»,gMt)) 
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Example 34 -Model Checking with Summarization 
The two-level model checking analysis is described in this section. The analysis 
maintains the following relations for performing summarization: 



5 Table 5 - Relations 



p 




Tid 


x (Global x Local#) 






x (Global x Localtt) 


Sum 


c 


Tid 


x (Global x Local#) 








x (Global x Ioca/#) 


Sum* 


c 


Tid 


^(Global x Ioca/#; 








^(Global x Z,oca/#; 








x Frame 


Sum' 




Tid 


^(Global x Zoca/#J 








x Frame 








x (Global x Zoca/#; 


Mark 




Tid 


^ (Global x Zoca/#; 
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Table 6 - Ruleset 3: Level II Summarization 

(CFL STEP) 

P{t,g x ,k,gM 

(CFL PUSH) 

P^gJ^h) U + {t,l 2 ,l 3 ,f) ^N{t,g 2 ,l 2 ) 
P(t,g 2 ,l 3 ,g 2 ,l 3 ) 

(CFL POP) 

Pit,giJx,g 2 A) U + {t,l 2 ,l„f) ->N(t,g 2 ,l 2 ) 

Sum-(t,g 2 ,l 3 ,f,g 3 ,I 4 ) 

Pi},g x ,h,gi,l A ) 

(CFL SUM") 

P{t,g^h,g 2 A) W(uhJ>h) ^N(t,g 2 ,l 2 ) 
Sum-{t,gJ x J,g 2 ,l 3 ) 

(CFL SUM) 

P(j 1 g 1 A 1 g2 1 hl N ^g 2 A) 

Sum{t,g x ,l x ,g 2 ,l 2 ) Mark(t,g i ,l l ) 
(CFL SUM + ) 

P(t,g x ,l x ,g 2 ,l 2 ) U + (t,l 2 ,l 3 ,f) ->N{t,g 2 ,l 2 ) 

Mark{t,g 2 ,l 3 ) 

Sum* (t, g l ,l i ,g 2 ,l 3 , f) Mark{t, g, , /, ) 

A model checking analysis can operate in two levels. The first-level 
reachability analysis maintains a set of reachable states Q, but it does not use U, U + , 

5 and (/"directly. Instead, it calls into a second-level summarization analysis that uses U, 
U + , and U~ to compute four relations: P, Sum, Sum*, and Sum'. Of these four relations, 
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the last three play roles similar to U,U*,U ', are used to communicate results back to 
the first-level analysis. Ruleset 2 gives the rules for the first-level reachability analysis 
and Ruleset 3 gives the rules for the second-level summarization analysis. 

Referring to elements of (Global x Locaf) as nodes, the relations P, Sum, Sum*, 
5 and Sum' are all edges since they connect a pair of nodes. The relation Mark is a subset 
of nodes. The relations Sum, Sum*, and Sum are maximal edges that are computed by 
the summarization rules (Ruleset 3). The reachability rules and the summarization rules 
communicate with each other in the following way: The rule (CFL START) creates an 
edge in P for a thread t when every other thread is outside a transaction. Once 

10 summarization has been initiated via (CFL START) from the first level, it continues for 
as long as a transaction lasts, that is, until the condition N(t,g 2 ,l 2 ) becomes true of a 
target state (g 2 ,l 2 ). The summary edges, Sum, Sum*, and Sum', generated by 
summarization are used by the reachability rules to do model checking, via rules STEP, 
PUSH, and POP in Ruleset 2. The P edges are used to initiate the computation in the 

15 summarization rules. The edges in P correspond to both "path edges" and "summary 
edges" in the context-free language (CFL) reachability algorithm for single-threaded 
programs. The rule (CFL STEP) is used to propagate path edges within a single 
procedure, and the rules (CFL PUSH), (CFL PROPAGATE), and (CFL POP) are used 
to propagate path edges across procedure boundaries. These four rules have analogs in 

20 the CFL reachability algorithm. 

FIG. 17 and FIG. 18 are block diagrams showing exemplary implementations of 
the reachability and summarization rules of Ruleset 2 (Level I) and Ruleset 3 (Level II), 
respectively. FIGs. 17 and 18 illustrate how the rules can work in two situations 
involving function calls. In these figures, a fixed thread identifier t is assumed, and 

25 nodes of the form (g, I) describe the global and local stores of thread t. A path edge 
(g,l) — ^(g f ,l f ) indicates that P{t,g,l,gT) is true; at a call the edge 
(gj) > (g'J') indicates that U*(t,lJ',f) is true, and at a return the edge 

(g> 1 ) U ~^ f) > (gV) indicates that U'{t,l,f,V) is true; edges labeled with Sum, Sum*, 
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and Sum' are interpreted similarly. Edges can be inferred from other edges in the 
figures. The inferred edges are dashed. 

In FIG. 17, a caller 1702 is being summarized from a state {g h //) 1710 to the 
point of call at a state (g 2 ,h) 1714 by a path edge P{t,g x J x ,g 2 J 2 ) 1712. Atthecall, 

indicated by an edge U + (t,l 2 J 3 ,f) 1716, a self loop P{t,g 2 J 3 ,g 2 J 2 ) 1720 on an entry 
state (g2, h) 1718 of a callee 1704 is inferred to start off a new procedure summary. 
After some computation steps in the callee 1704, a return point (g 3 , l 4 ) 1724 is reached, 
and a summary edge Sum ' (t , g 2 J 3 ,g 3 J 2 ) 1 728 * s inferred, which connects the entry 
state 1718 of the callee 1704 to the state 1730 immediately following the return 1724. 
Finally, a path edge P{t,g x ,l x ,g 3 J r 2 ) 1732 is inferred to connect the original state (gy, 
//) 1710 to the state 1730 following the return 1724. In this exemplary implementation, 
p {t, Si A >gi A ) is inferred by (CFL PUSH), P(t, g 2 J 3 ,g 3 J 4 ) is inferred by (CFL 
STEP), Sum-(t,g 2 J 3 ,g 3 J' 2 ) is inferred by (CFL SUM"), and P(t 9 g x J l9 g 3 J 2 ) is 
inferred by (CFL POP). 

The rules can handle the complications that arise from a transaction terminating 
inside a function. Due to such a transaction, a summary edge may end before the return 
point or begin after the entry point of a callee. The rules ensure that, if a summary for a 
function is only partial (e.g., it does not span across both call and return), then the 
reachability level will execute both the call and return actions, via the PUSH and POP 
rules. These situations could involve scheduling other threads before, during, or after 
the call, as defined by the reachability relation O. 

FIG. 18 illustrates inference of a partial summary for a function in which a 
transaction begins at an entry state (g 2 , 1 3) 1810 in a callee 1804 but ends (at a state (g 3 , 
l 4 ) 1812) before a return point (g 5 , l 6 ) 1816. A caller 1802 has states {g h lj) 1806 and 
(g 2 , h) 1808. The end of a transaction is indicated by the fact that N(t,g 39 1 4 ) 1822 is 
true. A partial summary up to the transaction boundary is cached in the edge 
Sum(t, g 2 ,l 3 ,g 3 J 4 ) 1818 which is inferred by the rule (CFL SUM). Because this 
summary does not span across the entire call, the reachability algorithm must execute 
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the call This is ensured by the inference of Mark{g 2 J 3 ) 1824 at the same time that the 
fact Sum(t,g 2 ,l 3 ,g 3 J 4 ) 1818 is inferred by (CFL SUM). The fact Mark(g 2 J 3 ) 1824 
allows the inference of Sum + (t,g l J l ,g 2 J 39 f) 1 826, which in turn is used by the 
reachability rule (PUSH) to execute the call. After executing the call, the partial 
summary edge Sum(g 2 ,l 39 g 3 J 4 ) 1818 is available to the reachability level, via rule 
(STEP). 

At state (g3, l 4 ) 1812 a new transaction summary begins via (CFL STEP). 
There is a self-loop P{t,g 3 J 4 ,g 3 ,l 4 ), not shown. The summary continues until the new 
transaction ends at (g 4 , h) 1814. At that point, the summary edge Sum(t y g 3 J 49 g 4 ,l $ ) 
1 820 is inferred by rule (CFL SUM). Finally, the summary Swn~ (t y g 4 ,/ 5 , /, g 5 J 2 ) 
1828 is inferred for the transition from (g 4i l 5 ) 1814 across the return point at (g 5 , l 6 ) 
1816 to a state (g 5 , lj) 1830, via rule (CFL SUM"). In this exemplary implementation, 
P(t,g 2 ,l3>g 2 ,h) is inferred by (CFL PUSH), Sum(t,g 2 J 3 ,g 3 J 4 ) is inferred by (CFL 
SUM), Mark(t, g 2 J 3 ) is inferred by (CFL SUM), Sum + {t,g l J l ,g 2 ,h,f) is inferred by 
(CFL SUM + ), Sum(t,g 3 J 4 ,g 4 ,l 5 ) is inferred by (CFL SUM), and 
Sum" (/, g 4 , / 5 , /, g 5 J 2 ) is inferred by (CFL SUM~). 

A summary edge (either Sum, Sum*, and Sum) may be computed by the 
summarization algorithm under any of the following three conditions: 

• When a transaction ends at an edge P(t , g x , /, , g 2 , / 2 ) (indicated by 
N{t f g2, h)) 9 the rule (CFL SUM) is used to generate a Sum edge. In 
addition, the start-state of the call is marked using Market, g/, //). 

• Whenever a start state of a call is marked, the rule (CFL SUM + ) 
generates a Sum + edge at every corresponding call site, and also 
propagates the marking to the caller. This marking can result in 
additional Sum* edges being generated by iterated application of the rule 
(CFL SUM*). 
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• When a procedure return is encountered, a Sum edge is generated by 
rule(CFL SUM"). 

The correctness of the analysis might depend on conditions CI and C2 (discussed 
above). However, since the analysis computes the least fixpoint over a different set of 
equations, the condition C3 is modified to the following condition C3 1 . In order to state 
condition C3 ' , the relation P{t 9 g l9 l l9 g 2 J 2 ) I" Sum(t 9 g x , l x , g 3 , l 3 ) is defined to hold if and 
only if there exists a proof tree using Ruleset 3 at whose root is an application of (CFL 
STEP) withP(t 9 g X9 l l9 g 29 l 2 ) among its premises and at one of whose leaves is an 
application of (CFL SUM) with Sum(t 9 g l9 l l9 g 39 l 3 ) among its conclusions. 
PfagiA'giA) h Sum-(t 9 g l9 l }9 f 9 g 3 J 3 ) and P(t,g l9 l l9 g 29 l 2 ) |- 
Sum + (t 9 g x J X9 g 3 J 39 f) are defined analogously (with applications of (CFL SUM") and 
(CFL SUM + ) at the leaves, respectively). 

C3\ If P{t,g l J i ,g 2 J 2 ) 2 ^L{f 9 g 29 l 2 ) 9 then on of the following conditions 
must hold: 

1. P(t 9 g l9 l l9 g 29 l 2 ) \- Sum(t 9 g l9 l l9 g 39 l 3 ) for some g 3 ,/ 3 . 

2. P{t 9 g x J X9 g 29 l 2 ) \- Sum-(t 9 g 19 l l9 f 9 g 39 l 3 ) for some g 3 ,/ 3 ,/. 

3. P{t 9 g X9 l X9 g 29 l 2 ) \- Sum + (t 9 g X9 l X9 g 39 l 39 f) for some g 3 J 3 ,f. 

Theorem 2: Let (g 0 > lso> U 9 U + 9 U~) be the instrumented multithreaded program. Let Q 
be the least fixpoint of the rules in Rulesets 2 and 3. Let the conditions CI, C2, and C3 ! 
be satisfied. If (go, lso, ss 0 ) — >* (g, ls 9 ss) and ls(t) = wrong, then there is {g\ ls' 9 ss*) 

and p such that Q(g f 9 ls\ ss*) and ls'(i) = (wrong, p). 

Proof: The proof of Theorem 2 depends on the following lemmas: 

Lemma 1: If Z(g, ls 9 ss) and ls(t) = (wrong, p) 9 then there is (g f 9 ls\ ss") such 
that I(g', /*', ss% ls\t) = (wrong 9 p) 9 and (g\ ls\u)) e N(u) for all u e Tid. 

Lemma 2: If £(g, ls 9 ss) and (g 9 ls(u)) e Af(u) for all u € Tid 9 then Q(g 9 ls 9 ss). 
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Lemma 3: If Is, ss) and (g, ls(t)) <£ M(t), then there are g f and /' such that 

P(t,g',l',g,ls(t)). 

Lemma 4: The condition C3 1 implies the condition C3. 

Lemma 3 is used to prove Lemma 4. Due to Lemma 4 and the preconditions of the 
theorem, the preconditions of Lemma 1 are satisfied. If (g 0 , lso, ss 0 ) — ►* (g, Is, ss) and 

ls(t) = wrong, then from Theorem 1, (g f , Is', ss") and p are obtained such that YXg\ k\ 
ss*) and ls'(t) = {wrong, p). From Lemma 1, (g", Is", ss") is obtained such that £(g", Is", 

ss"), ls"(t) = (wrong, p), and (g", ls"(u)) e N(u) for all u e Tid. From Lemma 2, Q(g", 
ls",ss") is obtained. 

Example 35 - Termination 

Sufficient conditions are presented for the least fixpoint Q of the rules in 

Rulesets 2 and 3 to be finite, in which case the disclosed summarization-based model 
checking analysis will terminate. These conditions are satisfied by a variety of realistic 
programs that use shared variables, synchronization, and recursion. 

A frame / e Frame corresponds to a procedure call and essentially encodes the 
values to which the local variables (e.g., the program counter) should be set, once the 
procedure call returns. Frame /is recursive if and only if there is a transition sequence 

(go, lso, sso) — ►* (g, Is, ss) and a thread t such that / occurs more than once in the stack 
ss(f). Frame /is transactional if and only if for all transition sequences (go, lso, sso) — >* 

(g, Is, ss) and for all u e Tid, if / occurs on the stack ss(t), then (g, ls(t)) g Af(t). If/is 

transactional, then in any execution, after a thread t pushes / on the stack, execution 
continues with all states outside M(t) until /is popped. 
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Theorem 3: Suppose the domains Tid, Global, Local, and Frame are all finite. If every 
recursive frame / € Frame is transactional, then the set of reachable states Q is finite, 
and the model checking analysis based on Rulesets 2 and 3 terminates. 

Proof: Because the sets Global, Local, Tid, and Frame are finite, it immediately follows 
5 that the relations P, Sum, Sum*, Sum'znd Mark computed by the summarization rules in 
Ruleset 3 are finite. First, the summarization rules acting on a sequence of transitions 
following the push of a recursive frame / are considered. The rule (CFL SUM) cannot 
be applied to any premise of the form P(t, g, I, g\ The reason is that /is 
transactional, and therefore (g ', £ Af(t). Hence, no facts of the form MarHt, g, I) or 

10 Sum(t, g, I, g\ can be deduced due to any pair (g f , /). Because, no such fact Market, g, 
I) can be deduced, the rule (CFL SUM + ), in turn, cannot be applied to any premise of 
the form P(t, g, I, g', and hence no fact of the form Sum* (t, g, I, g', l\J) can be 
deduced. 

The reachability rules for the set Q, acting on a sequence of states following the 
15 push of a recursive frame / are considered next. No facts of the form Sum(t, g, I, g\ l*) 
and no facts of the form Sum* {t, g, I, g', V,f) can be deduced. It follows that only the 
reachability rules (INIT), (STEP), and (POP) can be applied. Because none of these 
rules push frames on the stacks, only finitely many facts of the form Q(g, Is, ss) can be 
deduced from the push of a recursive frame. Since only the set Stacks can be infinite on 
20 any program, and because non-recursive frames can generate only finitely many distinct 
stacks, it follows that only finitely many facts Q(g, Is, ss) can be deduced from a 
program all of whose recursive frames are transactional. 

Example 36 - Single-Threaded Programs 
25 In a single-threaded program, the set Af(l) can be made for the single thread to 

contain just the initial state of the program and the states in which the thread has gone 
wrong. If the program does not reach an error state, then the rule (CFL SUM) can never 
be applied and the summarization rules will never generate Sum or Sum* edges. 
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Consequently, the reachability rules will never explore states in which the stack is non- 
empty, and the model checking analysis with summarization specializes to CFL 
reachability. The summary of a procedure contains only Sum' edges and is identical to 
the summary produced by the CFL reachability algorithm. 

5 

Example 37- Exemplary Computing Environment 

FIG. 19 and the following discussion are intended to provide a brief, general 
description of an exemplary computing environment in which the disclosed technology 
may be implemented. Although not required, the disclosed technology will be 

10 described in the general context of computer-executable instructions, such as program 
modules, being executed by a personal computer (PC). Generally, program modules 
include routines, programs, objects, components, data structures, etc. that perform 
particular tasks or implement particular abstract data types. Moreover, the disclosed 
technology may be implemented with other computer system configurations, including 

15 hand-held devices, multiprocessor systems, microprocessor-based or programmable 

consumer electronics, network PCs, minicomputers, mainframe computers, and the like. 
The disclosed technology may also be practiced in distributed computing environments 
where tasks are performed by remote processing devices that are linked through a 
communications network. In a distributed computing environment, program modules 

20 may be located in both local and remote memory storage devices. 

With reference to FIG. 19, an exemplary system for implementing the disclosed 
technology includes a general purpose computing device in the form of a conventional 
PC 1900, including a processing unit 1902, a system memory 1904, and a system bus 
1906 that couples various system components including the system memory 1904 to the 

25 processing unit 1902. The system bus 1906 may be any of several types of bus 

structures including a memory bus or memory controller, a peripheral bus, and a local 

bus using any of a variety of bus architectures. The system memory 1904 includes read 

only memory (ROM) 1908 and random access memory (RAM) 1910. A basic 

input/output system (BIOS) 1912, containing the basic routines that help with the 

30 transfer of information between elements within the PC 1900, is stored in ROM 1908. 
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The PC 1900 further includes a hard disk drive 1914 for reading from and 
writing to a hard disk (not shown), a magnetic disk drive 1916 for reading from or 
writing to a removable magnetic disk 1917, and an optical disk drive 1918 for reading 
from or writing to a removable optical disk 1919 (such as a CD-ROM or other optical 
5 media). The hard disk drive 1914, magnetic disk drive 1916, and optical disk drive 
1918 are connected to the system bus 1906 by a hard disk drive interface 1920, a 
magnetic disk drive interface 1922, and an optical drive interface 1924, respectively. 
The drives and their associated computer-readable media provide nonvolatile storage of 
computer-readable instructions, data structures, program modules, and other data for the 
10 PC 1 900. Other types of computer-readable media which can store data that is 

accessible by a PC, such as magnetic cassettes, flash memory cards, digital video disks, 
CDs, DVDs, RAMs, ROMs, and the like, may also be used in the exemplary operating 
environment. 

A number of program modules may be stored on the hard disk, magnetic disk 

15 1917, optical disk 1919, ROM 1908, or RAM 1910, including an operating system 

1930, one or more application programs 1932, other program modules 1934, and 

program data 1936. A user may enter commands and information into the PC 1900 

through input devices such as a keyboard 1940 and pointing device 1942 (such as a 

mouse). Other input devices (not shown) may include a digital camera, microphone, 

20 joystick, game pad, satellite dish, scanner, or the like. These and other input devices are 

often connected to the processing unit 1902 through a serial port interface 1944 that is 

coupled to the system bus 1906, but may be connected by other interfaces such as a 

parallel port, game port, or universal serial bus (USB). A monitor 1946 or other type of 

display device is also connected to the system bus 1906 via an interface, such as a video 

25 adapter 1948. Other peripheral output devices, such as speakers and printers (not 

shown), may be included. 

The PC 1900 may operate in a networked environment using logical connections 

to one or more remote computers, such as a remote computer 1950. The remote 

computer 1950 may be another PC, a server, a router, a network PC, or a peer device or 

30 other common network node, and typically includes many or all of the elements 
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described above relative to the PC 1900, although only a memory storage device 1952 
has been illustrated in FIG. 19. The logical connections depicted in FIG. 19 include a 
local area network (LAN) 1954 and a wide area network (WAN) 1956. Such 
networking environments are commonplace in offices, enterprise-wide computer 
networks, intranets, and the Internet. 

When used in a LAN networking environment, the PC 1900 is connected to the 
LAN 1954 through a network interface 1958. When used in a WAN networking 
environment, the PC 1900 typically includes a modem 1960 or other means for 
establishing communications over the WAN 1956, such as the Internet. The modem 
1960, which may be internal or external, is connected to the system bus 1906 via the 
serial port interface 1944. In a networked environment, program modules depicted 
relative to the personal computer 1900, or portions thereof, may be stored in the remote 
memory storage device. The network connections shown are exemplary, and other 
means of establishing a communications link between the computers may be used. 

Alternatives 

The technologies from any example can be combined with the technologies 
described in any one or more of the other examples. In view of the many possible 
embodiments to which the principles of the invention may be applied, it should be 
recognized that the illustrated embodiments are examples of the invention and should 
not be taken as a limitation on the scope of the invention. Rather, the scope of the 
invention includes what is covered by the following claims. We therefore claim as our 
invention all that comes within the scope and spirit of these claims. 



-44- 



